Skip to content

Version 0.2.1 — paste works, and fields fill their row - #12

Merged
timbogdanov merged 1 commit into
mainfrom
fix/paste-and-field-widths
Aug 19, 2026
Merged

Version 0.2.1 — paste works, and fields fill their row#12
timbogdanov merged 1 commit into
mainfrom
fix/paste-and-field-widths

Conversation

@timbogdanov

Copy link
Copy Markdown
Owner

What this changes

Two bugs reported from the Program sheet: an Anthropic API key could not be pasted into the key box, and the prompt field was too small. Neither turned out to be in that sheet.

Paste. electron/menu.js sets a custom application menu, which replaces macOS's default one wholesale — and on macOS the clipboard shortcuts inside web content are delivered by that menu. Its Edit menu had Undo, Redo, Select All, Deselect and Clear, and no Cut, Copy or Paste at all:

CLIPBOARD ROLES PRESENT: NONE

So Cmd+V had nowhere to go, in every text field in the app. Right-click offered nothing either, since Electron ships no context menu of its own and only the canvas had a custom one.

Each Edit item now does both halves: webContents[action]() for the text field (a no-op unless something editable has focus), then send(id) for the canvas, which the renderer drops while a field has focus. One key, whichever meaning the focus implies, and a menu item that still does what its accelerator does. Cut/Copy/Paste are new items; right-clicking an editable field now gets a menu built from the flags Chromium reports.

Two more from the same root:

  • Cmd+Z in a text field undid a brush stroke instead of a typo.
  • Clear was bound to a bare Delete. An unmodified key in the menu is swallowed application-wide, so Delete stopped deleting characters in every field — and fired alongside the renderer's own handler, clearing twice per press. The renderer owns it again; it already ignored text fields.

Field widths. .wide — the class meaning "fill the row" — was written input[type=number].wide. An attribute selector matches the attribute, so it skipped type="password" (the key field) and skipped an <input> written with no type at all (the prompt field). Measured in the running app:

field before after
API key 195px in a 491px row 353px
prompt 195px in a 491px row 412px

They missed the shared text-input rule for the same reason, which is why three fields carried duplicated inline styles — removed. And body{user-select:none} was inherited into every form field, so you could not select what you had just typed; inputs and textareas opt back in.

Verification

Drove the real window: put a key on the clipboard, focused #aiKey, fired the actual Paste menu item — the value lands, and the canvas is untouched by Undo/Select All while a field has focus. No renderer errors.

New regression checks in tools/verify-electron.py and tools/verify-ui.py, both of which fail on the code as it stood before this change. Full suite: 414 checks, 0 failures.

Checklist

  • npm run verify passes
  • Generated files re-run through their generator (stamps, codec fixtures) — none touched
  • If it touches the desktop app, the browser build still works — the menu-owned key list and the Edit commands are both behind native(); the CSS fixes apply to both builds
  • If it adds a stamp, the contact sheet was looked at — no stamps

🤖 Generated with Claude Code

https://claude.ai/code/session_01GRMJpT8yxY2Q33td1QeP7z

Setting a custom application menu replaces macOS's default one wholesale, and
on macOS the clipboard shortcuts inside web content are delivered by that menu.
The Edit menu here had Undo, Redo, Select All, Deselect and Clear — and no Cut,
Copy or Paste at all. Cmd+V had nowhere to go, so no text field anywhere in the
app could be pasted into; the API-key box in the Program sheet was simply not
fillable by anyone who keeps their key in a password manager. Right-click was
dead too, because Electron ships no context menu and only the canvas had one.

Each Edit item now does both halves: it asks the web contents to do the
text-editing action, which is a no-op unless something editable has focus, then
sends the canvas command, which the renderer drops while a field has focus. One
key, whichever meaning the focus implies. Two more bugs fell out of the same
root: Cmd+Z in a field undid a brush stroke, and Clear's bare `Delete`
accelerator was swallowed application-wide, so the key stopped deleting
characters everywhere — and fired alongside the renderer's own handler, clearing
twice per press. The renderer owns Delete again; it already ignored text fields.

The prompt and key boxes were narrow for an unrelated reason. `.wide` — the
class meaning "fill the row" — was written `input[type=number].wide`, and an
attribute selector matches the attribute, so it skipped `type=password` and
skipped an <input> written with no type at all. Both fields sat at 195px in a
491px row. They missed the shared text-input rule the same way, which is why
three of them carried inline copies of it; those are gone. body{user-select:none}
was inherited into every field, so you could not select what you had typed —
form controls opt back in.

Verified by driving the real window: a key on the clipboard, focus in the field,
the actual Paste menu item fired, and the value lands. Both regressions are held
by new checks in verify-electron.py and verify-ui.py, each of which fails on the
code as it stood.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GRMJpT8yxY2Q33td1QeP7z
@timbogdanov
timbogdanov merged commit a247814 into main Aug 19, 2026
5 checks passed
@timbogdanov
timbogdanov deleted the fix/paste-and-field-widths branch August 19, 2026 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant